一、什么是 Keystone ？
对软件研发团队来说，越是频繁地集成他们的代码，工作就越轻松。同时，越频繁发布功能迭代，产品就越有价值。但是团队并不想把开发了一半的功能暴露给用户。对这种矛盾的一个有效的处理机制就是先构建所有的后端代码，集成到产品，但不提供用户界面。这个功能可以在用户端无感知的情况下被集成和测试，直到全部完成上线后，再将这个功能展现给用户。就像是 Keystone（拱顶石，建筑学术语，通常引申为确保其他部件就位的核心关键点）。
二、限时特价促销活动
举一个简单的例子，比如说给用户推送一个限时特价商品。这样的订单一般都需要根据用户位置、配送情况等信息确定价格。所以根据用户位置、时间、商品类型等因素，决定了用户是否会收到这种限时特价商品的推送信息。
总而言之，这是一个很复杂的电商运作逻辑，因为需要涉及仓储量、商品目录、客户服务等多个系统的协同。完成这样一个流程的开发，可能需要几周的的时间，同时，另一些功能可能需要每隔几天就发布一次。而对客户而言，特价商品推送只是订单表格上的一个选择框。
在这个项目中，可以让选择框作为 Keystone。研发团队可以跨多个产品发布周期进行内部系统的业务逻辑和接口开发。用户感知不到这些代码改动。最后一步是让用户看到这个特价推送的选择框 UI 界面，通常这用不了多少开发时间。这种模式下，所有中间代码都能够参与集成，并随着产品发布周期部署在线上，这样就避免了长时间使用 feature branch（特性分支——一种分支管理模式）带来的风险。
三、中间代码和UI界面的测试方式
中间代码需要像线上代码一样接受严格的测试。这需要系统（测试）分层搭建，而不是所有测试都依赖于用户页面的触发。单元测试和 Test Pyramid（测试金字塔）中的低层测试都应当可以正常执行。甚至 Broad Stack Test 都可以正常执行，只要提供一定的机制使它们成为 Subcutaneous Tests。某些情况下，UI 层本身包含了复杂的行为，不过只要设计得当，UI 也可以通过进入 Humble Object 的方式得到测试。
并非所有应用程序的构建方式都支持这种大覆盖面的"皮下"测试，但即使无法使用 Keystone 模式，这种设计原则也是有价值的。即使用最好的工具去自动化这一过程，从 UI 层触发的测试也总是很难搭建的。将更多的测试转移到界面层以下各层级，特别是单元测试层，可以显著提升部署流水线的速度，实现持续交付。
当然，大多数的 UI 变化会比添加一个选择框复杂，即便如此，应用 Keystone模式也并不会增加太多工作量。在 Web 应用中，一个复杂的功能通常都是一个独立页面，可以作为一个整体构建和测试。这种场景下，Keystone 就是一个链接。桌面应用可能设计多个界面变化，这种情况下，Keystone 可以是一个能展示这些界面的菜单项。
尽管如此，确实存在一些场景用户界面不能被简单地打包通过一个 Keystone 控制。这时候就需要用到功能开关了。即便在这种情况下，Keystone 的概念也能够帮助我们将功能开关的实现限定在UI层控制上。这样可以避免开关四处散落在后端代码中，降低了开关应用的复杂性，更好地贯彻单开关机制，也为后续的开关清理降低了难度。
四、总结
后端先行，最后再开发 UI 界面的方式也存在一个潜在的风险，就是后端代码的设计可能无法与后开发的UI协调一致，或者在后期UI实现时才发现设计点遗漏，这会导致反馈延迟并带来糟糕的用户体验。因此，只有在产品上支持功能垂直划分，研发上能够按功能粒度快速发布的团队中，Keystone 模式才能够发挥最大的价值。
在这里我只是举例了一个用户界面的小例子，但同样的方法适用于任何界面变化，例如 API。通过最后再提供用户界面，并且保持简洁的方式，即使是很大的功能升级，我们也可以通过逐个部分增量构建、集成来完成。
在 FeatureProbe 就可以实现 Keystone 模式，做到后端代码与UI 界面分开部署测试。研发团队可以先开发后端代码部署，用户侧无感知这一块功能核心功能已经部署到系统上了，确保新功能后端代码没有问题后，在 FeatureProbe 后台操作页面，可以一键开启 UI 界面功能，测试 UI 界面功能没有问题后，再将这个新功能开放给用户。
目前 FeatureProbe 使用 Apache 2.0 License 协议已经完全开源。你可以从 GitHub 或 Gitee 获取到所有源码。